feat: adding attachments to snippets. - #3421

core/thread.py:2020

• ext includes forwarded attachments (added just above), but the loop only iterates over message.attachments, so forwarded attachments appended to ext are never classified into images/attachments and won't be included in the outgoing embed/log.

        for i, a in enumerate(message.attachments):
            attachment = ext[i]
            if getattr(a, "is_snippet_attachment", False):

bot.py:1413

• This replaces the original message attachments with only the snippet attachment. If a user invokes a snippet while also attaching files, those files will be silently dropped.

            if attachment is not None:
                snippet_message = copy.copy(message)
                snippet_message.attachments = [attachment]
                ctx.message = snippet_message

bot.py:1386

• This overwrites any attachments present on the original alias-invoking message when a snippet attachment exists, so user-provided attachments would be dropped instead of being sent along with the snippet attachment.

This issue also appears on line 1410 of the same file.

                        attachment = await self._download_snippet_attachment(snippet_data)
                        if attachment is not None:
                            context_message.attachments = [attachment]
                    else:

cogs/modmail.py:363

• The help text hard-codes a 10 MB limit, but the actual limit is configurable via snippet_attachment_max_size (default 10). This can mislead users if the config is changed.

        You can also attach a file (max 10 MB) to include with the snippet.

cogs/modmail.py:399

• confirm_msg is only defined inside the if ctx.message.attachments: block, but it’s referenced later unconditionally (if confirm_msg:). When adding a text-only snippet (no attachment), this will raise an UnboundLocalError.

        # Handle optional attachment
        file_id = None
        attachment_info = None
        if ctx.message.attachments:

cogs/modmail.py:363

• The docstring hard-codes “max 10 MB”, but the actual limit is configurable via snippet_attachment_max_size (default 10). This will become inaccurate if the config is changed.

        You can also attach a file (max 10 MB) to include with the snippet.

cogs/modmail.py:846

• The attachment upload error is logged without a traceback, which makes diagnosing intermittent Discord/Mongo/GridFS failures difficult. Log with exc_info=True and avoid stringifying the exception separately.

            except Exception as e:
                logger.error("Failed to upload snippet attachment: %s", e)

core/clients.py:860

• download_snippet_attachment will currently raise InvalidId or NoFile if the stored file_id is malformed or missing. Callers handle this as a generic exception, but it would be better to translate these expected failure modes into a clear, consistent error (mirroring delete_snippet_attachment, which treats them as benign).

        grid_out = await self.fs.open_download_stream(ObjectId(file_id))

cogs/modmail.py:564

• The attachment upload error is logged without a traceback, which makes diagnosing intermittent Discord/Mongo/GridFS failures difficult. Log with exc_info=True and avoid stringifying the exception separately.

This issue also appears on line 845 of the same file.

            except Exception as e:
                logger.error("Failed to upload snippet attachment: %s", e)

core/thread.py:2273

• This warning doesn’t include which snippet attachment failed to convert, which makes it hard to debug if multiple attachments are ever supported or filenames collide. Include the filename (best-effort) in the log message.

                discord_files.append(await att.to_file())
            except Exception:
                logger.warning("Failed to convert snippet attachment to file.", exc_info=True)

core/thread.py:2120

• Snippet images are embedded via attachment://{filename} before the code attempts to build discord_files. If to_file() fails for any reason, the embed will reference an attachment that wasn’t actually sent, resulting in a broken image. Consider converting to discord.File first and only calling embed.set_image(url="attachment://…") when you know the corresponding file will be included in the send call.

        # Handle snippet images first (embedded directly)
        for a in snippet_images_to_upload:
            if not embedded_image:
                embed.set_image(url=f"attachment://{a.filename}")
                embed.add_field(name="Image", value=a.filename)
                embedded_image = True
            # Always add to files_to_upload so the attachment is physically present
            files_to_upload.append(a)

cogs/modmail.py:918

• If you keep an existing attachment when no new file is uploaded, this block should only delete old_file_id when it is being replaced. As written, it will delete the old attachment even for text-only edits.

        if old_file_id:
            old_attachment_deleted = await self._delete_snippet_attachment(old_file_id, name)

cogs/modmail.py:893

• snippet_edit currently drops old_file_id when no new attachment is provided, so a text-only edit will implicitly remove any existing attachment. That makes it impossible to edit snippet text while keeping the stored attachment, and can cause accidental data loss.

This issue also appears on line 917 of the same file.

        updated_snippet = {"text": new_text or ""}
        if new_file_id:
            updated_snippet["file_id"] = new_file_id

bot.py:1394

• In alias expansion, command_invocation_text already includes invoked_prefix, but you also prepend invoked_prefix again when creating the StringView. This results in a duplicated prefix (e.g., ??fpreply ...), which can prevent alias->snippet invocations from being parsed correctly.

                    command = self._get_snippet_command()
                    command_invocation_text = f"{invoked_prefix}{command} {snippet_text}"
                view = StringView(invoked_prefix + command_invocation_text)

cogs/modmail.py:865

• This exception handler logs only the exception message, dropping the traceback. Using logger.exception (or exc_info=True) will preserve stack traces for attachment upload failures during snippet edits.

            except Exception as e:
                logger.error("Failed to upload snippet attachment: %s", e)

core/thread.py:2283

• When converting snippet attachments to Discord files fails, the warning log doesn’t include which attachment failed, making it hard to diagnose problematic files in production logs. Include the filename (when available) in the warning.

        for att in files_to_upload:
            try:
                discord_files.append(await att.to_file())
            except Exception:
                logger.warning("Failed to convert snippet attachment to file.", exc_info=True)

cogs/modmail.py:577

• This exception handler logs only the exception message, dropping the traceback. Using logger.exception (or exc_info=True) will preserve stack traces, which is important for diagnosing GridFS upload failures.

This issue also appears on line 864 of the same file.

            except Exception as e:
                logger.error("Failed to upload snippet attachment: %s", e)

bot.py:1322

• The download failure log drops the traceback and doesn’t include which file_id failed, which makes it hard to debug GridFS/ObjectId issues. Log the file_id and include exc_info=True.

        try:
            file_data, metadata = await self.api.download_snippet_attachment(snippet_data["file_id"])
        except Exception as e:
            logger.warning("Failed to download snippet attachment: %s", e)
            return None

core/clients.py:897

• On unexpected GridFS deletion failures, the warning log only includes the exception message. Include exc_info=True so the traceback is preserved for debugging.

        except Exception as e:
            logger.warning("Failed to delete snippet attachment %s: %s", file_id, e)
            return False